Note:	Text displayed in blue italics is included to provide guidance to the author and should be deleted or hidden before publishing the document.
This template can be used at it is, or to complete and improve an already existing template.

Project QA and Collaboration Plan 
for
<project name>

Distribution: 
<Org., Name>

Appendices: 
<Appendix 1>

•	Help:	The purpose of the Project QA and Collaboration Plan is to document all activities and collaboration procedures that are required to execute the project successfully within its constraints. 

Contents
1. Organization
1.1 Project-internal Functions
1.2 Change Control Board (CCB)
2. Schedule and Budget
2.1 Schedule and Milestones
2.2 Budget
2.3 Execution Process
2.4 Collaboration Environment
3. Communication and Reporting
4. Quality Assurance
4.1 Standards and Procedures
4.2 Quality Audits
4.3 Verification and Validation Activities
5. Configuration and Change Management
5.1 Configuration Management
5.1.1 Configuration Items
5.1.2 Baselines
5.1.3 CM Tools and Resources
5.2 Change Management
5.2.1 Change Procedure
5.2.2 Change Management Support
6. Abbreviations and Definitions
7. References
8. Revision

1.	Organization
1.1	Project-internal Functions
Help:	Since the project manager has the overall project responsibility, he /she is also responsible for the project-internal functions. But he/she can delegate the management of these functions to project team members. In this case list the functions and individuals responsible for
Example:

Function	Organization: Name	Comment	
Quality Assurance			
System Test Lead			
Validation Lead			
Configuration Mgmt			
Change Mgmt			
etc.			

1.2	Change Control Board (CCB)
Help:	Released work products and baselines can only be changed on agreement of the responsible change Control Board (CCB). In complex projects different levels of CCBs may be defined (see help text in section 12.2 Change Management).
Example:

A CCB is responsible for reviewing and approving all change requests on baselined plans and work products, e.g. Project Plan, Project Requirements Specification, Design, etc. Two CCBs are define in this project:
CCB: for reviewing and approving all changes within the project that affect project goals and scope. It consists of:
Organization	Name	

		
		
2.	Schedule and Budget
2.1	Schedule and Milestones
Help:	Estimate the effort for the project activities and plan the activity sequencing. Then prepare the schedule that supports all of the required activities and complies with the resource plan.
Define project milestones based on the chosen development strategy and on critical events in the project schedule.
List the milestones and define clear milestone criteria to make milestones measurable.

Milestones	Description	Milestone Criteria	Planned Date	
M0		Start Project	Budget Release	<yyyy-mm-dd>	
		e.g.: Project goals and scope defined	PRS or SRS reviewed 
Stakeholders identified
Impl. Proposal reviewed	<yyyy-mm-dd>	
M1		Start Planning		<yyyy-mm-dd>	
		<milestone description, 
e.g. Life Cycle Objectives LCO defined>	Scope and concept described	<yyyy-mm-dd>	
M2		Start Execution		<yyyy-mm-dd>	
		<milestone description,
e.g. Life Cycle Architecture LCA defined>	Requirements agreed, project plan reviewed, resources committed	<yyyy-mm-dd>	
M3		Confirm Execution		<yyyy-mm-dd>	
		<milestone description, 
e.g. alpa version>	Architecture reviewed and stable	<yyyy-mm-dd>	
M4		Start Introduction		<yyyy-mm-dd>	
		<milestone description,
e.g. system test passed>	Coding of new functionality finished,
Draft documentation	<yyyy-mm-dd>	
M5		Release Product		<yyyy-mm-dd>	
		<milestone description>	Product system tested, documentation reviewed	<yyyy-mm-dd>	
M6		Close Project		<yyyy-mm-dd>	
A detailed Project Schedule is available in [4]. The Project Schedule is monthly updated by the Project Manager.

2.2	Resources
Help:	List the required project resources based on estimates for project activities, sub-contracts, training, etc. Present the distribution of the resources over the whole project life.

Category	Budget for Period in kUS$	
	M0-M1	M1-M2	M2-M3	M3-M4	M4-M5	M5-M6	
Human Resources (internal)							
Human Resources (external)							
Travel 
(for internal people)							
Travel 
(for external people)							
Equipment and Tools
(internal)							
Equipment and Tools
(external)							

Help:	Prepare a resource plan specifying the project's need for human resources, as well as for other resources (equipment, tools, licenses, etc.).

2.3	Execution Process
Help:	If available and applicable refer to the organizational development process and describe deviations from this standard process. Otherwise describe the execution process applied in this project and agreed with your outsourcing partner..
Explain why this execution process has been selected. Describe how the selected execution process is tailored to the needs of the project. 

2.4	Collaboration Environment
Help:	Define methods, tools, languages, etc. to be employed for design, implementation, test, and documentation, and when they (or knowledge) should be available.
Example:

Item	Applied for	Availability by	
Methods			
Use Case	Requirements capturing	M0	

Tools			
Rational Rose	Design	M2	

Languages			
UML	Design	M2	
Java	Web interface	M2	
C++	…	M2	

3.	Communication and Reporting 
3.1	Recurring Project Communication 

Help:	State the principles for reporting and distributing information among the stakeholders within the project (internal, i.e. own project team and outsourcing partners) or outside the project ( external, e.g. project sponsor). Include, for example, how often the reporting will take place, the type of reports or information, the type of media in which it is presented, and the type of meetings that will take place. 
a)	Internal communication and reporting: ensure that all information is available to those who need it.
– Plan project meetings, how often they take place, and who will participate
– Define how project information will made available to the internal stakeholders (e.g. project library)
– Define how and how often sub-projects and sub-contractors report to the project manager
– Define who participates milestone meetings
– Define how events will be communicated
b)	External communication and reporting:
– Define what information will be provided to which stakeholders
– Define how and how often information will be provided to which stakeholders often (e.g. project report) 
– Plan regular meetings with external stakeholders (e.g. SteCo meetings)
Example:

Type of Communication	Method / Tool	Frequency/Schedule	Information	Participants / Responsibles	
Recurring Communication Activities Project Internal:	
Project Meetings	Teleconference 	Weekly and on event	Project status, problems, risks, changed requirements	Project Mgr
Project Team
Sub-contractor	
Sharing of project data	Shared Project DB
	When available	All project documentation and reports	Project Mgr(s) 
Project Team Members	
Sub-contract Reports	Word document	Bi-weekly	Sub-project status
- progress
- forecast
- risks	Sub-contractors	
Milestone Meetings	Teleconference 	Before milestones	Project status (progress)	Project Mgr
Sub-project Mgr
Sub-contractor	
SteCo Meetings	Teleconference with SameTime	Monthly		Project Manager, SteCo	
Final Project Meeting	Teleconference 	MS6	Wrap-up
Experiences	Project Mgr
Project Team
Sub-contractor	
Communication Activities Project External:	
Project Report	Excel sheet	Monthly	Project status
- progress
- forecast
- risks	Project Manager
Sub-Project Managers
Sub-contractors	
SteCo Meetings	Teleconference with SameTime	Monthly		Project Manager, SteCo	

3.2	Problem Escalation and Resolution 
Help:	Describe how problems and conflicts within the project team and the outsourcing partner shall be resolved (different conflicts, different levels of management involvement).

4.	Quality Assurance
Help:	The Quality Assurance Plan (QA Plan) can be either a separate document or included in the project plan. If the QA Plan is a separate document refer to it in this chapter. If not, the subchapters below should be used.
4.1	Standards and Procedures 
Help:	List the policies, standards, and directives as well as externally imposed standards that shall be taken into account in the project. Refer to the relevant descriptions. 
Describe any special agreements that have been made with the customer. 

Policy/Directive/Standard/etc	Reference	Comment	

			
			
Special Agreements:
<None or description>

4.2	Quality Audits 
Help:	Specify all quality audits to objectively verify compliance to policies, standards, and defined procedures.
Also plan quality audits on sub-projects and sub-contracts (e.g. contract audits, etc.).
Define the responsibility for calling the audits and how they are being coordinated and reported.

Subject of Q-Audit	Time	Responsibility/Comment	

			

4.3	Verification and Validation Activities 
Help:	Specify all verification and Validation (V&V) activities to be performed in the project.
Verification aims at evaluating a work product or a deliverable to determine whether it satisfies all demands and conditions defined for its development. Verification answers the question: are we developing the thing right? 
Verification procedures are typically reviews, inspections, and tests.
Validation aims at evaluating a work product or project deliverable during or at the end of the execution process to determine whether it satisfies the specified requirements and expectations. Validation answers the question: are we developing the right thing?
Validation activities are typically assessment of prototypes, review of project requirements with the customer, acceptance test of sub-contractor deliverables or acceptance test of the project deliverables with the customer or end user.

Specify all work products and deliverables to be verified and/or validated and define the verification/validation procedure to be used. For each verification activity define the responsibilities. 
Examples:

Work Products	V & V Activity	Responsible	Reference	
	Activity	Type			
<Requirements Specification>	<Review>	Ver	Author, Reference Group ID	Review procedure [x]	
<Functional and Design Description>	<Review>	Ver	Author, Reference Group ID	Review procedure [x]	
<Sub-system x>>	<Subsystem test>	Ver	Sub-contractor x	Techn. Proj. Mgr.	
<Alpha Release>	<System Test>	Ver	Test lead	Project Manager	
<Beta Release>	<onsite test>	Val	BetaTest Group	Test Plan [x],
Test Spec [y]	
<Release>	<acceptance test>	Val	Techn. Proj. Mgr.	End User	

5.	Configuration and Change Management
5.1	Configuration Management
Help:	The Configuration Management Plan (CM Plan) can be either a separate document or included in the project plan. If the CM Plan is a separate document refer to it in this chapter. If not, the subchapters below should be used.
It is assumed that Configuration Management (CM) is supported by a dedicated CM Tool. The tool mainly influences the CM procedure, Library structure, identification scheme, access rights, etc.
Therefore only the following information has to be included in the CM section of the project plan:
•	Which CM Tool is used
•	Which resources for CM are needed
•	Which work products are taken under CM control
•	Which baselines should be built

5.1.1	Configuration Items
Help:	Identify all Configuration Items (CI) to be taken under CM control. A configuration Item is a work product that is designated as a single entity for configuration management. CIs are developed in the project or received from suppliers and sub-contractors. 
CIs are typically:
•	Source files (code, makefiles, scripts, etc.)
•	Binary files 
•	Technical documentation (specifications, design documents, test cases, etc.)
•	Project documentation (plans, reports, etc.)
•	Etc.

5.1.2	Baselines
Help:	Define major baselines for this project, their purpose and their relation to the project’s milestones.

Baseline	At Milestone	
ID	Purpose/Description		

			

5.1.3	CM Tools and Resources
Help:	Identify all resources (human resources, equipment, tool, training) required for performing Configuration Management. Required CM equipment and support persons should be identified in the resource plan and commitments for their time obtained from the ‘resource owners’. Identify the budget required for CM in the Budget section, and training needs in the Training Plan section.
Example:

CM Tool	Number of licenses	
Identification	Description		

			

Resources	Description	
CM Equipment	<None or see section 5.1 (Resource Plan)>	
CM Training	<None or see section 5.2 (Training Plan)>	

5.2	Change Management
Help:	Two levels of changes should be distinguished:
•	Changes on the Project Management Level affecting goals and scope of the project (e.g. requirements, budget, release date etc.) 
•	Changes on the Execution Layer not affecting goals and scope of the project (e.g. design, code, etc.)
Typically a special CCB is established for each level of changes. However the same change procedure can be applied to both levels.
5.2.1	Change Procedure
Help:	If available refer to the organizational change procedure and add project specific aspects only. Otherwise define the change management procedure (and tools) applied in this project. It should specify the steps for handling changes and roles involved in the change management process. It should also define how approved changes are communicated to the affected stakeholders. 
Example:
Change requests are used to track changes to baselines. Any stakeholder can submit change requests. Change requests can describe identified defects or demands to change goals and scope of the project. The authorized CCB (see section …) has to accept a change requests before work on it is initiated, and also accept all resulting changes before a new baseline is created. Approved changes are communicated directly after the CCB decision to the affected stakeholders and in the project meetings to the whole development team.

5.2.2	Change Management Support
Help:	Describe how change Management is supported, e.g. a dedicated tool, templates, email based system, etc.
Example:
The organizational Change Request Management tool (CRM tool) is used for the documentation and management of change requests. Stakeholders without access to the CRM tool submit change requests via email to the project member responsible for change management (see section ...) who will take them over into the CRM tool.

6.	Abbreviations and Definitions
Help:	List all abbreviations and definitions used within this document.
CCB	Change Control Board
CI	Configuration Item
CM	Configuration Management
COTS	Commercial Off The Shelf
CR	Change Request
CRM	Change Request Management
QA	Quality Assurance
SteCo	Steering Committee
V&V	Verification and Validation

7.	References
Help:	List all other documents this document refers to.
[1]	<Doc. No.>	Project Plan for <project name>
[2]	<Doc. No.>	Project Requirements Specification for <project name>
[3]	<Doc. No.>	Implementation Proposal for <project name>
[4]	<Doc. No.>	Project Schedule for <project name>
[5]	<Doc. No.>	Risk Management Plan for <project name>
[6]	<Doc. No.>	Work Breakdown Structure for <project name>
[7]	<Doc. No.>	Configuration Management Plan (if it is a separate plan)
[8]	<Doc. No.>	<Sub-contract #1>
[9]	<Doc. No.>	

8.	Revision 
Rev. ind.	Page (P)
Chapt. (C)	Description	Date
Dept./Init.	
-	---	original version